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ABSTRACT 

The SPAcecraft SIMulator (SPASIM) simulates the 
functions and resources of a spacecraft to quickly perform 
Phase A trade-off analyses and uncover any operational 
bottlenecks during any part of the mission. Failure modes 
and operational contingencies can be evaluated allowing 
optimization for a range of mission scenarios. The payloads 
and subsystems are simulated, using a hierarchy of graphical 
models, in terms of how their functions affect resources such 
as propellant, power, and data. Any of the inputs and outputs 
of the payloads and subsystems can be plotted during the 
simulation. Most trade-off analyses, including those that 
compare current versus advanced technology, can be 
performed by changing values in the parameter menus. 
However, when a component is replaced by one with a 
different functional architecture, its graphical model can also 
be modified or replaced by drawing from a component 
library. SPASIM has been validated using several spacecraft 
designs which were at least at the Critical Design Review 
level. The user and programmer guide, including figures, is 
available on line as a hyper text document. This is an easy- 
to-use and expand tool which is based on MATLAB® and 
SIMULINK®. It runs on SGI workstations and PCs under 
Windows 95® or NT®. 

INTRODUCTION 

The primary function of the SPAcecraft SIMulation 
(SPASIM) software is to create a virtual environment to 
simulate a spacecraft. The simulation includes the 
spacecraft's operation and the interaction of multiple 
subsystems as a function of time and resources. SPASIM 


presents this virtual environment to the user in a 
graphical/object-oriented interface to enhance usability and 
integration. 

SPASIM defines a hierarchy of block diagrams wired 
together along with parameters that describe operational and 
performance characteristics that yields a well documented 
functional spacecraft model. The top level block diagram is 
shown in Figure 1 . Each block within a graphical user 
interface (GUI) window defines a function or a hierarchy of 
lower level blocks. Blocks at the lowest level invoke 
MATLAB® or SIMULINK® code. The GUI presents a 
dialog box to the user that allows changes to be made to a 
block's parameters before simulation starts. Lines connecting 
the blocks transmit values such as those used to represent 
orbital information and spacecraft resources. Examples of 
these resources are propellant, power, and data. 

The user can analyze subsystem interactions during a 
simulation by displaying a dynamic plot of any block's input 
or output values. A large selection of predefined plots may 
be chosen by clicking on the "Spacecraft Parameters" button 
and choosing the plot menu from the pop-up window. 

SPASIM includes a library of models of spacecraft 
payloads and subsystem components that represent a range 
of functionality. The user and programmer guide (Liceaga et 
al. 1997), including figures, may be accessed by clicking on 
the "Online Help" button. 

SPASIM is one of the tools in the Satellite System Design 
and Simulation Environment (Ferebee, Troutman; and 
Monell 1997). This environment also includes a design and 
sizing tool and a component database. 
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Figure 1: Main Window 


SPACECRAFT PAYLOADS 


The payloads are the instruments the spacecraft carries to 
accomplish its mission. By default, there are four payloads 
which are shown in Figure 2. 
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Figure 2: Spacecraft Payloads 

Resource requirements and state information from the 
subsystems flow in from the left. They are distributed to the 
payloads which output their requirements. Finally, the 
requirements of each payload are added and feed back to the 
subsystems as the payload resource requirements. 


All payloads share a standard interface. They have access 
to the same state and orbital information from the 
subsystems. They can also add to any of the spacecraft 
resource requirements. 

SPACECRAFT SUBSYSTEMS 


The spacecraft subsystems provide the resources required 
for the mission to be accomplished. Together they make up 
what is commonly called the spacecraft bus. As shown in 
Figure 3, the spacecraft bus is modeled as being composed 
of the following subsystems: power; thermal; propulsion; 
guidance, navigation, and control (GNC); communication 
and tracking (CT); and command and data handling (CDH). 



Figure 3: Spacecraft Subsystems 

Payload resource requirements flow in from the left. The 
subsystem requirements are added and feed back to the 
subsystems as the spacecraft resource requirements. 

All subsystems share a standard interface. They have 
access to the same spacecraft resource requirements and 
orbital information. They can also add to any of the 
spacecraft resource requirements. 

Each subsystem has a parameter menu. These parameters 
are used as constants or the initial value of variables. 


Power 

The purpose of the power subsystem is to generate, store, 
and distribute electrical energy. It is implemented through a 
solar array (produces power), a battery (stores power), and a 
charge unit (controls power). It tries to point the solar array 
normal vector as close as possible toward the sun to 
maximize the amount of energy generated. 

The parameters in the main power menu include the: 
average minimum solar flux, solar cell type, individual solar 
cell efficiency, solar array active area, solar cell degradation 
factor, initial solar array efficiency, solar array shadow file 
name, solar cell in-service time, power bus efficiency, 
nominal bus voltage, and number of degrees of freedom 
(DOF) of the solar array. The solar array shadow file is an 
ASCII file, loaded before the start of the simulation, and 
used by a two-dimensional look-up function in 
SIMULINK®. This look-up function linearly interpolates 
the fraction (0.0 to 1.0) of the solar array area available at 
specific alpha and beta angles for the spacecraft in a nominal 
local vertical local horizontal (LVLH) flight attitude. 

The parameters in the battery menu are: maximum energy 
capacity, cell type, charging efficiency, initial charge, 
minimum operational depth of discharge, maximum charge 
rate, and maximum discharge rate. 

The inputs to this model are the: spacecraft power 
requirement, sun vector, earth vector, and sunlight flag. Its 
outputs are a battery charging flag, the power it requires, and 
the rate at which it generates data. 

This model has defined plots of time versus: spacecraft 
power requirements, power margin, depth of discharge, solar 
alpha, solar beta, shadow table result, initial power factor, 
and power factor. 

Thermal 

The purpose of the thermal subsystem is to maintain 
spacecraft components within specified temperature limits. 
The model implemented in SPASIM assumes a cold biased 
system in which given regions are designed to operate below 
the upper temperature limits of the components therein. 

Since this often results in the temperatures, in that region, 
falling below the lower limits of the components, 
thermostatically controlled heaters are often employed. 
Components that can’t be effectively cold biased are cooled 
by passive (stored cryogen and radiative) and/or active 
(closed cycle and thermoelectric) coolers. 


This model also allows the user to simulate custom 
heater/cooler power profiles. The heaters/coolers are either 
keyed to a day/night switch or are available on an on- 
demand basis. Once 'on' the heaters/coolers will follow a 
user defined power profile. Note that because of their more 
restrictive temperature requirements, batteries are assumed 
to be on a different cold biased loop where heaters are keyed 
to the charge state of the batteries. 

The parameters in the thermal menu specify the power 
requirements for: a cryocooler; the battery heater used when 
neither charging nor discharging; and the payload, 
propellant, and GNC electronics heaters used during eclipse. 

The inputs to this model are the battery charging flag from 
the power subsystem and the sunlight flag from the GNC 
subsystem. Its outputs are the power it requires and the rate 
at which it generates data. This model has defined a plot of 
time versus thermal power requirement. 

Propulsion 

The purpose of the propulsion subsystem is to provide the 
thrust required to maintain or change the spacecraft’ s orbit 
and attitude. This subsystem uses two resources, propellant 
and power. The model implemented is strictly an event 
driven process. Until the GNC subsystem is modeled as a 
mass-accurate system, this model will stay as an stochastic 
model. The subsystem is implemented through twelve 
thrusters. Four thrusters are required to provide the positive 
and negative torques about each of the three axes. 

The parameters in the propulsion menu specify the: initial 
fuel load contained in the tanks for the mission, specific 
impulse of the propulsion subsystem, minimum time a 
thruster can remain on after an on/off command is issued, 
output thrust of one thruster, amount of fuel burned for each 
second of engine firing time, number of operational 
propulsion events to occur in a year, and time the first event 
will occur from the start of the simulation. 

The output of this model is the power it requires. This 
model has defined plots of time versus thruster power 
requirement and propellant tank level. 

The following three assumptions were used in creating the 
stochastic resource model for the propulsion subsystem. 
First, thruster events are modeled as periodic throughout one 
year. Second, thruster events will have a duration of the 
thruster's minimum impulse time. Third, a thruster firing 
sequence will have a duration of two hours. The sequence in 
seconds is as follows: at 0, pitch channel thrusters go off; at 
90, negative pitch channel thrusters go off; at 3600, positive 



roll channel goes off; at 3690, negative roll channel goes 
off; at 7200, positive yaw channel goes off; and at 7290, 
negative yaw channel goes off. Thus, the thruster firings for 
a specific period take 7290 seconds to complete. 

Guidance, Navigation, and Control 

The purpose of a typical GNC subsystem is to provide 
orbital and attitude determination and control. However, 
passive or active attitude control isn’t simulated. Instead, 
attitude motion can be prescribed with one of the following 
three methods: fixed, oscillatory, or user prescribed. In 
fixed, the user specifies an initial attitude and the spacecraft 
is held fixed at that attitude. In oscillatory, the user specifies 
amplitudes and frequencies for the three axes. In user 
prescribed, an input file with a proper attitude history is 
given. This can be the result of an off-line three DOF or a 
six DOF simulation. It is assumed that the control system 
can meet the user prescribed attitude profile. There are two 
attitude modes available to the user. An Earth oriented 
LVLH mode and an inertial mode. When in inertial mode, 
the user can specify a spin rate. 

The parameters in the main GNC menu specify the: 
attitude flight mode, either LVLH or inertial; initial 
spacecraft attitude; spacecraft spin rate; spacecraft spin axis; 
attitude history type, either fixed, oscillatory, or user 
prescribed; repeat attitude history flag, if user prescribed no 
value matching at beginning or end; oscillatory amplitudes 
and frequencies for the three axes; and user prescribed 
attitude history file name. 

The parameters in the orbit menu specify the launch time, 
simulation start time, spacecraft lifetime, and epoch time. 

For this epoch time, they also specify the: apogee, perigee, 
inclination, argument of periapsis, and ascending node. 

The orbital information this model outputs is calculated by 
three submodels: orbital propagator, attitude determinator, 
and earth and solar pointer. The orbit propagator integrates a 
simple two body orbit equation using a Runge-Kutta type 
integrator based on Fehlberg's seventh-order formula to 
calculate: radius, true anomaly, velocity, flight path angle, 
eccentricity, longitude, and latitude. The attitude 
determinator calculates the spacecraft's attitude in terms of 
yaw, pitch, and roll angles. The earth and solar pointer 
outputs the: sun vector, earth vector, and sunlight flag. 

The model also outputs the power it requires and the rate 
at which it generates data. This model has defined plots of 
time versus: yaw, pitch, roll, earth vector, sun vector, and 
sunlight. It has also defined a plot of latitude versus 
longitude. 


Communications and Tracking 

The purpose of the CT subsystem is to communicate with 
ground stations to download data and upload commands. 
The carrier-to-noise ratio of both the telemetry downlink and 
the command uplink is calculated as a figure of merit for the 
channel carrying capability of the link. 

The power flux density (PFD) is calculated at both the 
ground station site and at the spacecraft during a contact 
coverage period. This feature helps determine if the link has 
enough power at the receiver to accept a data transfer link. 
Because of the change in slant range due to continuously 
changing position of the spacecraft with respect to the 
ground station, calculating the PFD gives an indication of 
the received power range while the ground contact is made. 

It can help in the design and analysis process for either a 
ground station or a spacecraft communications subsystem. 

The radio frequency (RF) link margin between the space 
and ground communication segments is calculated to give an 
indication of RF performance levels available to maintain 
adequate communication. Based upon requirements such as 
bit-error-rate, the link margin gives the theoretical potential 
of the link to perform to certain specifications. If the 
calculated performance exceeds requirements, savings can 
be realized by relaxing the ground or spacecraft 
communications subsystem design. 

The main CT menu includes parameters for the: 
transmitter, receiver, RF link, and typical ground station. It 
also includes flags to indicate whether Consultative 
Committee for Space Data Systems formatting and/or Reed- 
Solomon error coding are used. The transmitter parameters 
are: frequency, power, antenna beam width, antenna 
diameter, antenna type, line loss, antenna gain, and effective 
isotropic radiated power. The receiver parameters are: 
frequency, sensitivity, antenna beam width, antenna 
diameter, antenna type, antenna system noise temperature, 
antenna pointing error, and antenna gain. The RF link 
parameters are the uplink data rate and energy-per-bit to 
noise-density ratio (E]/N 0 ), and the downlink data rate and 
E b /N 0 . The parameters for a typical ground station are: 
antenna system noise temperature, antenna diameter, 
transmitter power, receiver noise bandwidth, minimum 
elevation, maximum time to acquire station, and maximum 
time to loss of signal. 

SPASIM also allows the user to select which ground 
stations are active through a ground station menu. The other 
parameters in this menu are the ground station: name, 
latitude, longitude, and altitude. Currently there are 18 



stations defined. The user can add or delete from this list 
through this menu. 

The inputs to this model are the: radius, longitude, 
latitude, and net downlink rate from the CDH subsystem. 
This is the maximum rate at which the CDH subsystem can 
send data for downlinking. Its outputs are the power it 
requires, the rate at which it generates data, and the 
maximum net downlink rate. The maximum net downlink 
rate is the maximum rate at which the CT subsystem can 
accept data for downlinking. 

This model has defined plots of time versus: downlink 
status, slant range, spacecraft power flux, spacecraft link 
margin, ground power flux, and ground link margin. 

Command and Data Handling 

The purpose of the CDH subsystem is to store and retrieve 
data and commands and to execute those commands. Its 
model simulates the utilization of the data processing and 
storage capabilities and the requirements placed on other 
subsystems. 

The parameters in the CDH menu specify the: maximum 
net processing rate, maximum storage capacity, maximum 
record rate, maximum playback rate, pre-storage formatting 
overhead, pre- storage error coding overhead, sensor 
sampling rate, number of CDH analog sensors, number of 
CDH discrete sensors, unallocated data rate, unallocated 
instruction rate, and time stamp size. The maximum net 
processing rate is the number of instructions per second that 
the processor can allocate to the spacecraft’ s processing 
requirements. Operating system and other software 
overheads as well as required processor margins are 
deducted from the raw processor capability to get this 
number. 

The sensor sampling rate indicates how many times the 
spacecraft sensors need to be sampled per second. The data 
and instruction rates needed to support this function for the 
CDH subsystem are calculated based on this rate and how 
many analog and discrete sensors are in this subsystem. The 
unallocated data and instruction rates are the rates needed to 
support this function in the subsystems whose models do not 
calculate them. The time stamp size indicates the minimum 
number of bits needed to identify the time at which payload 
and housekeeping data was taken. 

The inputs to this model are: the spacecraft data rate 
requirement, the spacecraft instruction rate requirement, and 
the maximum net downlink rate from the CT subsystem. The 
spacecraft data rate requirement is the rate at which payload 


and housekeeping data is generated. This data has to be 
stored until it can be downlinked. 

The spacecraft instruction rate requirement is the number 
of instructions per second that the processor needs to 
execute to meet the requirements of the spacecraft. The rate 
at which the processor is executing instructions is subtracted 
from this input. The resulting rate is integrated to calculate 
the number of instructions queued. 

The maximum net downlink rate is the maximum rate at 
which the CT subsystem can accept data for downlinking. 
This rate is zero when the spacecraft is not in contact with a 
ground station. 

This model has four outputs. Three of these are the 
contributions from this model to the spacecraft power 
requirement, the spacecraft data rate requirement, and the 
spacecraft instruction rate requirement. The fourth is the net 
downlink rate which is the maximum rate at which the CDH 
subsystem can send data for downlinking. 

This model has defined plots of time versus: data stored, 
spacecraft data rate requirement, data lost, spacecraft 
processing requirement, and processing queue. 

SUMMARY 

SPASIM can be used to validate spacecraft design and 
sizing estimates by performing an integrated time simulation 
of the spacecraft. This identifies resource bottlenecks or 
inadequacies resulting from simplified assumptions. Since 
SPASIM is a time based simulation, discrete events and duty 
cycles can be modeled and their resulting impacts can be 
assessed across all the spacecraft. Failure modes and 
operational contingencies can be evaluated allowing the 
analyst to optimize the spacecraft performance for a range of 
mission scenarios. The SPASIM interface allows the analyst 
to easily change system functional architectures via block 
diagrams and to easily update performance characteristics of 
system components with parameter input menus. By 
changing specific parameters in a model, the user can assess 
the impacts of using different technologies. 

SPASIM has been validated using several spacecraft 
designs which were at least at the Critical Design Review 
level. The user and programmer guide, including figures, is 
available on line as a hyper text document. This is an easy- 
to-use and expand tool which is based on MATLAB® and 
SIMULINK®. It runs on workstations from Silicon 
Graphics, Inc. and personal computers under Windows 95® 
or NT®. 
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